1. Field of the Invention
The present invention relates to the design of computer networks. More specifically, the present invention relates to a method and an apparatus for transparently interconnecting multiple network links into what appears to be a single virtual network link.
2. Related Art
Bridges are commonly used to transparently interconnect many physical links into what appears to the Internet Protocol (IP) (or a layer 2 protocol) to be a single LAN. However, this transparency is bought at a price. It requires the topology on which traffic is forwarded to be a tree. This causes traffic concentration on links that were chosen for the spanning tree. It also causes suboptimal paths.
In addition, bridge forwarding can be dangerous. There is no hop count in the header, and worse yet, bridges forward onto multiple ports (when the location of the destination is unknown), and multiple bridges might choose to forward a packet seen on a link. This causes exponential proliferation of packets. As a result, bridges need to be conservative about forwarding onto new links, in order to avoid temporary loops. The spanning tree as originally designed used a timer to avoid temporary loops (see Perlman, R., “A Protocol for Distributed Computation of a Spanning Tree in an Extended LAN”, 9th Data Communications Symposium, Vancouver, 1985). Since then various optimizations have been proposed, such as making a special case of ports for which the neighbor is known to be an endnode (rather than another switch). If the assumption is correct that the neighbor is an endnode, there is no danger of loops by immediately starting to forward on that port.
Given the possibility of exponential proliferation during temporary loops, the spanning tree technique can become unstable. Attempts to make it less conservative in order to forward more quickly are likely to increase the number of such incidents. In a distributed technique, there is no way, based on totally local information, for a bridge to know it is safe to start forwarding onto a new link. And even if such a technique were to be devised, a component such as a repeater can cause a loop which bridges would not be able to prevent.
So why not simply use routing? The IP protocol (v4) is pretty much universal. However, it is not universal. There are other layer 3 protocols that are in use, and there are some protocols, such as intermediate system-to-intermediate system (IS-IS), or local area transport (LAT), which work directly over layer 2.
Even if the IP protocol were universal, however, it has a disadvantage. IP routes only to links. Each link is assigned an address prefix, and all IP nodes on that link must have an IP address with that prefix, and any node not on that link must have an IP address that does not start with that prefix. That means that a node that has multiple links must have multiple addresses, and a node that moves from one link to another must change its address.
Note that for the purposes of this disclosure, IPv6 is sufficiently similar to IPv4 that throughout this disclosure “IP” is intended to mean both IPv4 and IPv6. Differences such as the use of the “neighbor discovery” protocol for IPv6 vs. ARP for IPv4 are straightforward translations of functionality.
Another disadvantage of IP routing is that it requires configuration. It has improved over the years with the addition of protocols such as the Dynamic Host Configuration Protocol (DHCP). However, the routers need to be configured with prefixes for the links. There have been proposals for having routers within a campus, given a prefix, automatically subdivide the prefix into link-specific prefixes, so that each link within a “campus” would automatically have its own unique prefix within the shorter campus-wide prefix. This approach avoids configuration of the routers, but still has disadvantages:                a node that moves within the campus must change its address;        a node that has attachments to multiple links must have multiple addresses; and        it is wasteful of IP addresses, since it is impractical to make sure that every link is fully populated (makes full use of its prefix).        
The ConnectionLess Network Protocol (CLNP) is a protocol similar to IP (see “Protocol for Providing the OSI Connectionless-Mode Network Service”, ISO 8473). However, unlike IP, in CLNP there is no link-specific prefix. Instead there is the concept of “level 1 routing” within an area. An area may contain many links. All nodes within the area share the same prefix. A node with multiple links within the area can have a single layer 3 address, and a node that moves within the area need not change its layer 3 address. CLNP could do this because all CLNP endnodes implemented a protocol known as the End-System-to-Intermediate-System (ES-IS) protocol. The ES-IS protocol has endnodes periodically announce themselves, to an address listened to by the routers, so that all the routers on the link know which endnodes are on that link, and can detect (based on no longer receiving ES Hello messages) when an endnode has gone down or moved.
Because of the ES-IS protocol, an area can have an arbitrary physical topology and routers can route to endnodes using a shortest path technique. Unfortunately, IP endnodes cannot be relied upon to do any such announcements.
Hence, what is needed is a method and an apparatus for transparently interconnecting multiple network links into what appears to be a single virtual network link without the problems described above.